Fixes: #3326

Rationale: we have 4 distinct types which are all passed around as Vec<u8>. Just until recently this seemed good enough (though absolutely against static typing and a "everything is a type approach" that leverages the compiler), until it didn't. I spent a good couple of days trying to find a regression that I introduced, which was a simple copy-pasta caused by using a Vec<u8> Sierra where Casm was actually expected. That was enough.

The PR introduces 4 types:

• SerializedSierraDefinition
• SerializedCasmDefinition
• SerializedCairoDefinition
• SerializedOpaqueClassDefinition, where the internal Vec<u8> is either sierra or cairo, but we don't really care because it's all passed around to the end consumer without the need to figure out which variant it really is; this is also how classes are stored and served via the RPC
• SerializedClassDefinition, which is the opposite of the above - it's an enum, which distinguishes between the two variants

I tried to make the changes transparent and not modify the semantics of the APIs, with one notable exception: compute_class_hash, where it actually made sense to consume the buffer and reinterpret it as either of the variants in a safe manner, so that download_class itself does not have to do the reinterpreting in an unsafe manner.

I left all the fixtures as is to keep the delta reasonably small (which it already isn't).